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REMARKS 

The Examiner has rejected claims 1 - 5, 7 - 12, and 14-26 under 35 
U.S.C. 103(a) as being unpatentable over WOLF et al. in view of ABEL et al. 
The Examiner has rejected claims 6 and 13 under 35 U.S.C, 103 as being 
unpatentable over WOLF et al. in view of ABEL et al. in further view of LEVIN et 
al. Applicant respectfully traverses. 

The References Relied upon by the Examiner Are Non-analogous 
The references relied upon by the examiner are non-analogous. "Two 
criteria have evolved for determining whether prior art is analogous: (1) whether 
the art is from the same field of endeavor, regardless of the problem addressed, 
and (2) if the reference is not within the field of the inventor's endeavor, whether 
the reference still is reasonably pertinent to the particular problem with which the 
inventor is involved. In re Deminski, 796 F.2d 436, 442, 230 USPQ 313, 315 
(Fed. Cir. 1986); In re Wood, 599 F.2d 1032, 1036, 202 USPQ 171. 174 (CCPA 
1979)." 

The claimed invention is in the field of enabling customers to create 
interactive voice response (IVR) services. More specifically, the claims relate to 
customizing an IVR service application for a customer. The customer can 
implement the customization relatively easily and quickly, without involving 
source code programming. The customer can use building blocks that contain 
complex functionality to help create the custom IVR applications. 

In contrast, ABEL et al. pertain to routing communications from a central 
processing unit to one of a plurality of remote locations. As described in col. 3, 
lines 10-20, ABEL et al. enhance and ensure reciprocity in the sending of 
orders among florists and provide a more efficient method of making payment 
settlements. Such a system ensures that merchants located in or who serve a 
specific area receive reciprocal (incoming) orders in proportion to their sending 
activity in relation to the sending activity of other florists members located in or 
servicing the same area. Generally speaking, ABEL et al. ensure and enhance 
referrals or reciprocal business, as stated at col. 4, lines 46 - 49. 
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Thus, it is submitted that the routing control program of ABEL et al. is not 
in the same field of endeavor (i.e., enabling customers to easily create IVR 
applications) as the claimed invention. Moreover, it is submitted that the 
programming taught by ABEL et al. is entirely unrelated to the problem the 
claimed invention solves. More specifically, ABEL et al. provide no discussion or 
suggestion of simplifying and facilitating creation of IVR service applications. As 
stated in paragraphs 0003 - 0005. the claimed invention is directed to the 
problem of the complicated source code programming typically required to create 
custom IVR applications. Consequently, ABEL et al. is non-analogous art. 

There Is No Motivation to Combine WOLF with ABEL et al. 

Even if the references are considered analogous (which they are not), 
There is no suggestion, motivation, incentive, or reason to combine the 
references in the manner proposed by the examiner, except that provided in 
applicant's specification. "[T]he record must provide a teaching, suggestion, or 
reason to substitute computer-controlled valves for the system of hoses in the 
prior art. The absence of such a suggestion to combine is dispositive in an 
obviousness determination." See SmithKline Diagnostics, Inc. v. Helena Lab. 
Corp., 859 F.2d 878, 886-87, 8 USPQ2d 1468, 1475 (Fed. Cir. 1988). 

The examiner has not provided a proper reason for the proposed 
combination. The examiner states that "it would have been obvious to one of 
ordinary skill in the art at the time the invention was made to modify the invention 
of WOLF using the system database as taught by ABEL et al. This modification 
of the invention of WOLF would enable each designer tool kit modules [sic] 
having a database that is separate from the dynamic interactive database so that 
the system would ensure that merchant who are locate [sic] in remote area 
receive incoming orders." 

Merchants located in remote areas would not be guaranteed to receive 
incoming orders because of the proposed combination. Remote merchants 
would receive incoming orders because service is desired in their remote area. 
For example, if a merchant is located in South Dakota, and a customer wants 
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flowers to be delivered in South Dal^ota, the South Dakota merchant would 
receive the order, even if the order was called into a merchant local to the 
customer, simply because the merchant is located at the destination desired by 
the customer. The teachings of WOLF (i.e., how to create a user customizable 
IVR system) are unrelated to ensuring that remote merchants receive incoming 
orders. 

The examiner has equated WOLF's voice templates with the claimed 
designer tool kit modules (DTKs) and presumably with the claimed feature 
specific node types. WOLF*s voice templates are described at col. 4, lines 18 - 
27, and also at col. 6, - col. 7, line 54. Essentially, the voice templates include 
messages that will be played to a caller who calls into the IVR. In the example 
shown in Fig. 4, the voice template is "Press 1 to leave a message for Richard." 
Creating extra databases for each voice template would not appear to cause the 
result claimed by the examiner, i.e., ensuring remote merchants would receive 
incoming orders. 

Furthermore, creating a separate database for each voice template would 
result in an unmanageable system due to the large number of required 
databases. The voice templates of WOLF are very basic components of the IVR 
system. Many voice templates would be used in a typical IVR application 
because each voice template corresponds to a single item in a single menu. Of 
course numerous items can be provided in each menu, and an unlimited number 
of menus can be provided (see col. 4, line 13-18 where WOLF states the 
number of menus and records per menu is unlimited). Thus, a very large 
number of voice templates (which are a subset of menu records) is likely. If each 
individual voice template has its own database, a very large number of individual 
databases would have to exist. Thus, the combination would not make sense. 

In view of all of the reasons described above, it is submitted that no 
motivation exists for combining the references, as the examiner has proposed. 

The Combination of WOLF and ABEL et al. Does Not Teach or Suggest All of 
the Limitations of Claims 1. 7, 14. 16. 17, and 20 



4 



P21784 A08 



Even if combined, the references fail to teach all the limitations, namely: 
Claim 1 requires "A method for implementing a customized instance of a 
dynamic interactive voice system ... the method comprising: configuring a call 
flow that incorporates ... a plurality of standard nodes and a plurality of 
preprogrammed designer tool kit modules, each designer tool kit module having 
a database that is separate from the dynamic interactive database, at least one 
of the designer tool kit modules being a call library application, at least one of 
the designer tool kit modules being a zip code locator module, and at least one 
of the designer tool kit modules being a voice forms module . . ." Claim 7 recites 
"A method for configuring for a customer a customized instance of a dynamic 
interactive voice application ... the method comprising: storing a plurality of 
nodes . , . comprising at least one standard node type . . . and a plurality of 
preprogrammed feature specific node types, at least one of the feature specific 
node types being a call library application, and at least one of the feature specific 
node types being a zip code locator module . . ." 

In contrast, the applied references do not teach or render obvious to one 
having ordinary skill in the art, at least, the specifically claimed applications. For 
example, a call library application is required by claim 1. With respect to this 
limitation, applicant is acting as his own lexicographer. 

To understand this term, the specification should be consulted, as held by 
the Federal Circuit, sitting en banc, in PHILLIPS, v. AWH CORPORATION (03- 
1269, -1286 July 12, 2005) The claims, of course, do not stand alone. Rather, 
they are part of "a fully integrated written instrument," Markman , 52 F.3d at 978, 
consisting principally of a specification that concludes with the claims. For that 
reason, claims "must be read in view of the specification, of which they are a 
part." Id. at 979. As we stated in Vitronics , the specification "is always highly 
relevant to the claim construction analysis. Usually, it is dispositive; it is the 
single best guide to the meaning of a disputed term." 90 F.Sd at 1582. 

This court and its predecessors have long emphasized the importance of 
the specification in claim construction. In Autoqiro Co. of America v. United 
States . 384 F.2d 391, 397-98 (Ct. CI. 1967), the Court of Claims characterized 
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the specification as "a concordance for the claims," based on the statutory 
requirement that the specification "describe the manner and process of making 
and using" the patented invention. 

The specification is, thus, the primary basis for construing the claims." 
Standard Oil Co. v. Am. Cvanamid Co. . 774 F.2d 448, 452 (Fed. Cir. 1985). That 
principle has a long pedigree in Supreme Court decisions as well. See Bates v. 
Coe, 98 U.S. 31 . 38 (1878) ("in case of doubt or ambiguity it is proper in all cases 
to refer back to the descriptive portions of the specification to aid in solving the 
doubt or in ascertaining the true intent and meaning of the language employed in 
the claims"); White v. Dunbar 119 U.S. 47, 51 (1886) (specification is 
appropriately resorted to "for the purpose of better understanding the meaning of 
the claim"); Schriber-Schroth Co. v. Cleveland Trust Co. , 311 U.S. 211, 217 
(1940) ("The claims of a patent are always to be read or interpreted in light of its 
specifications."); United States v. Adams . 383 U.S. 39, 49 (1966) ("[l]t is 
fundamental that claims are to be construed in the light of the specifications and 
both are to be read with a view to ascertaining the invention."). 

Consistent with that general principle, our cases recognize that the 
specification may reveal a special definition given to a claim term by the patentee 
that differs from the meaning it would otherwise possess. In such cases, the 
inventor's lexicography governs. See CCS Fitness. Inc. v. Brunswick Corp. , 288 
F.3d 1359, 1366 (Fed. Cir. 2002). 

As required by the courts, the examiner is respectfully directed to 
paragraphs 0045 - and 0046 of the specification, which explains a call library 
module. The call library module allows a customer's caller to select and hear 
pre-established voice announcements and messages from a customer 
maintained library. It also enables the configuration application to send faxes 
from a customer-maintained library of facsimile messages, which may 
correspond to the voice announcements. 

The complex functionality required by a call library application is not 
taught or suggested by the proposed combination. The examiner appears to rely 
upon Fig. 1 and col. 6, line 50 - col. 8, line 35 of ABEL et al. to support the 
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rejection. Those passages, as well as the rest of the reference do not disclose 
any type of call library, much less the claimed call library, described in the 
specification. 

The portion relied upon by the examiner describes a subscriber database 
that stores information about each subscriber. Exemplary fields include zip 
codes served by the florist, name, address, number of orders sent, number of 
orders received, etc. The selection database merely includes a subset of the 
subscriber database. See col. 7, lines 29 - 33. No call library functionality is 
provided by the selection database or the subscriber database. 

The transaction database stores account billing and operational data. 
Exemplary fields include credit card information, number or orders sent and 
received, etc. No mention or suggestion of a call library is provided. The zip 
code database references street addresses and cities to their appropriate zip 
codes. Again, no mention or suggestion of a call library function is provided by 
the zip code database. 

Clearly, at least a DTK with the complex functionality of a call library is 
missing from the proposed combination. 

Moreover, the databases of ABEL et al. are not comparable to the 
claimed DTKs and feature specific node types. Thus, even though ABEL et al. 
disclose a zip code database, the claim term (e.g., of claim 16) requires a zip 
code locating node that is executable by the IVR application according to a call 
flow of a customized instance of a dynamic interactive voice application. 
Paragraph 0049 further describes the claim term as enabling a customer's caller 
to find nearby customer locations based upon the callers' respective zip codes. 
The database of ABEL does not provide any such functionality, and is not 
executable, as required by claim 16. 

Several of the claims also require a voice forms module. As described in 
paragraphs 0047 and 0048, the voice forms module enables customers to define 
a collection of automated audio forms that are completed by a caller over a 
DTMF telephone, thereby collecting and organizing information from the caller. 
None of the databases of ABEL et al. include customer defined fields. Rather, 
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each database field is defined by ABEL et al. Moreover, as noted above with 
respect to claim 16, ABEL et al's databases are not executable. 

More generally speaking, the claims define a capability to design an IVR 
application with building blocks. DTKs are one type of building block. As stated 
in paragraph 0040, the DTK modules are pre-designed to address select 
functionality that is anticipated to be in demand by multiple customers. Claimed 
examples of such functionalities include the call library, zip code locator, and 
voice forms modules. In contrast, WOLF only provides very generic very basic 
tools to create an IVR application. No thought is given to actually creating more 
complex building blocks, such as the claimed DTKs, to simplify the design of an 
IVR application. With respect to the claim language of claims 7, 16, and 20, 
"feature specific node types" are submitted to be patentably distinguishable from 
the generic functionality of WOLF's voice templates. 

The mere fact that ABEL et al. disclose multiple databases would not lead 
one of ordinary skill in the art to create a separate database for each of WOLF's 
voice templates. As mentioned above, a separate database for each voice 
template would yield too may databases to be practical. In addition, just 
because separate databases exist, does not lead one of ordinary skill in the art 
to incorporate that teaching into WOLF et al., especially because the multiple 
databases of ABEL et al. are for use by the overall routing controller program, 
i.e., the overall system. Thus, there is no teaching of a different database for 
different components of the overall system, as required by claim 1 . 

Consequently, for at least these reasons, it is requested that the Examiner 
withdraw the rejections of independent claims 1, 7, 14, 16, 17, and 20 and 
provide an indication of their allowability. 

Dependent claims 2 - 6, 8 - 13, 15, 18, 19, and 21 - 26 are also believed 
to recite further patentable subject matter of the invention and therefore are also 
believed allowable over the prior art. As such, allowance of the dependent 
claims is deemed proper for at least the same reasons noted for the independent 
claims, in addition to reasons related to their own recitations. Accordingly, 
applicant respectfully requests reconsideration of the outstanding rejections and 
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an indication of tlie allowability of all of the claims in the present application. 

The above amendments have been presented merely for the purpose of 
clarification, and not to overcome the applied prior art. Accordingly, no estoppel 
is deemed to result from any of the present amendments. 

Should the Examiner have any questions, the Examiner is invited to 

contact the undersigned at the below-listed telephone number. 

Respectfully submitted, 
M. PLAN 



Bruce H . Bernstein \N\\V»an> t. "^^^ 
Reg. No. 29,027 ^eQ. No- ' 



October 31, 2005 

GREENBLUM & BERNSTEIN, P.L.C. 
1950 Roland Clarke Place 
Reston.VA 20191 
(703)716-1191 
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